The Telecommunications Standards Section of the International Telecommunication Union (sometimes designated as ITU-T) provides recommendations to facilitate the standardization of the telecommunications industry. ITU-T recommendation G.994.1 (often referred to as G.HS) defines a handshaking protocol where preliminary information is exchanged between a central office transceiver and a remote transceiver. In general, this handshaking protocol defines the transceivers' capabilities and parameters for the connection between them. Recommendation G.994.1 is herein incorporated by reference in its entirety. The G.HS protocol employs multiple tones in parallel to give resilience in the presence of interference, whereas earlier handshaking techniques used a single tone and were susceptible to external interference. For instance, the single tone could be displaced by interference thereby preventing handshaking from proceeding. Given the robust nature of G.HS, it has been a very popular handshaking protocol and it has been widely implemented.
Field experience has shown, however, that G.HS connections are sometimes affected by cross talk interference. Cross talk is present in data transmission when two wires are close enough to each other that one of them generates energy in the other due to coupling. Two potential types of cross talk coupling are generally referred to as near-end cross talk (NEXT) and far-end cross talk (FEXT). Given the robust nature of the G.HS protocol (despite FEXT being a relatively weak signal), FEXT of G.HS. signals may cause false triggering of connections in adjacent lines. In addition, FEXT of G.HS. signals may cause G.HS connections to be established between different pairs in a cable bundle.
To avoid FEXT false connections, a modification to the G.HS protocol may be used to indicate the busy or idle status of the upstream channel during establishment of a G.HS session. This modified protocol superimposes a busy signal on existing tones from the modem to create busy tones. For reference, the modem may be referred to as a Central Office (CO) modem, the tones as C-TONES, and the busy tones as C-TONES-BUSY. C-TONES-BUSY enables the CO modem to indicate if it is initiating the handshake or if it is responding to a remote terminal (RT) modem that is initiating the handshake.
G.HS allows the RT modem to indicate if it is initiating or responding. If initiating, the RT modem sends a request signal that may be referenced as R-TONES-REQ. If responding, the RT modem sends a response signal that may be referenced as R-TONE1.
In operation, a CO modem initiates a session using C-TONES signals. The RT modem on the primary line responds with R-TONE1. RT modems on adjacent lines may receive the C-TONES signals due to FEXT and respond with R-TONE1. CO modems on adjacent lines are expecting the R-TONES-REQ signal and thus do not communicate. When a RT modem initiates a session, it sends a R-TONES-REQ signal. The CO modem on the primary line responds with C-TONES-BUSY. CO modems on adjacent lines may receive the R-TONES-REQ signal due to FEXT and respond with C-TONES-BUSY as well. RT modems on adjacent lines recognize the C-TONES-BUSY signal as a response and do not communicate.
The modification to the G.HS signaling protocol by the CO and RT modems helps to prevent the inadvertent initiation of G.HS sessions in adjacent wire pairs due to FEXT. The modified signaling protocol further reduces signal collision when multiple G.HS RT modems reside on the same telephone line. This signaling protocol requires that CO modems transmit C-TONES-BUSY in response to R-TONES-REQ. The CO modem does not respond to R-TONE1 unless it just transmitted C-TONES. The RT modem does not respond to C-TONES-BUSY unless it just transmitted R-TONE-REQ.
Although the modified G.HS signaling protocol reduces the likelihood of false starts due to FEXT, it is still problematic. For example, assume that a RT modem initiates and sends R-TONES-REQ and a CO modem responds with C-TONES-BUSY. Due to FEXT, other CO modems may respond with C-TONES-BUSY. Only the initiating RT modem responds with R-TONES1. Other adjacent RT modems will not respond since they receive the C-TONES-BUSY and know that they did not initiate the session. A problem associated with this first scenario is that the RT modem may receive the desired C-TONES-BUSY signal as well as FEXT C-TONES-BUSY signals. If a FEXT C-TONES-BUSY signal comes before the desired C-TONES-BUSY, the initiating RT modem may start communicating with the wrong CO modem. Moreover, this communication may be disrupted by the true and stronger C-TONES-BUSY signal, thereby causing the G.HS handshake to fail. This process may repeat.
Another problem occurs if the true C-TONES-BUSY signal is not received for some reason. This may happen, for example, if the CO modem is disconnected. As a result, a false connection with an adjacent CO may be established due to FEXT. Yet another problem is that the RT modem may continue a handshake with multiple CO modems for a certain time period before terminating the process.
In a second scenario, assume the CO modem initiates a handshake session by sending C-TONES. RT modem responds with R-TONE1. Adjacent RT modems may receive C-TONES due to FEXT and respond with R-TONE1. The CO modem responds to a received R-TONE1 by sending a response signal that may be referred to as C-GALF1. Other adjacent CO modems will not respond since they receive R-TONE1 instead of R-TONES-REQ. A problem associated with this scenario is that the initiating CO modem may receive the desired R-TONE1 signal as well as FEXT R-TONE1 signals. If a FEXT R-TONE1 signal comes before the desired R-TONE1, the CO modem starts communicating with the wrong RT modem. This communication may be disrupted by the true R-TONE1 thereby causing the G.HS session to fail.
Another problem is that the CO modem may not receive the true R-TONE1 for some reason. In such a case, a connection with an adjacent RT may be established through FEXT. Yet another problem is that the CO modem may undergo a handshake session with multiple RT modems for an undue period of time.
Thus, signaling methods with the G.HS protocol are only partially effective in reducing G.HS false connections in adjacent lines. Completion of a desired G.HS handshake session is not guaranteed since such completion may be affected by false responses from a remote end of an adjacent line. Furthermore, if a desired remote end does not respond for some reason, communication through FEXT may commence. There is a need, therefore, for improved methods for reducing false starts due to FEXT.